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EXAMINER S ANSWER 



This is in response to the appeal brief filed 01/03/2007 appealing from the Office action mailed 
06/01/2006. 
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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial proceedings 
which will directly affect or be directly affected by or have a bearing on the Board's decision in 
the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection contained in 
the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

6108700 Maccabee et al. 8-2000 

6356282 Roytman et al. 3-2002 

6314103 Medhatetal. 11-2001 

6230203 Koperda et al. 5-2001 
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6304892 



Bhoj et al. 



10-2001 



(9) Grounds of Rejection 



The following ground(s) of rejection are applicable to the appealed claims: 



Claim Rejections - 35 USC § 103 



The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness 
rejections set forth in this Office action: 

A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of 
this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject 
matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art 
to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made. 

Claims 1, 23, 24, 26 and 27 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Maccabee et al. (6108700) (hereinafter Maccabee) in view of Roytman et al. (6356282) 
(hereinafter Roytman) in further view of Medhat et al. (6314103) (hereinafter Medhat). 

As per claim 1, as closely interpreted by the Examiner, Maccabee teaches a method for 
managing network services associated with a service level management domain to provide 
service level management, the method comprising the steps of, (e.g. col. 6, lines 10 - 30 & col. 
7, lines 37 -60): 

monitoring, by a plurality of monitoring agents, operational characteristics of a network service 
associated with a service level management domain and supporting one or more business 
processes under service level management, each monitoring agent detecting events of a select 
type of the associated operational characteristics from the network service and mapping such 
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events into alarms, (e.g. col. 7, lines 37 - 60, "sensors" to also be interpreted as "agents" 
"When appropriate, the sensor generates an event that describes the change in state, when the 
where it has occurred, and any extra data necessary to uniquely identify the event (e.g., an event 
describing that a file has been opened might include the name of the fie as well as the file 
handle returned by the open activity for use in subsequent file accesses). "); 
transmitting the alarms from the plurality of monitoring agents to an alarm correlation agent, 
which analyzes the alarms to produce correlated alarms, (e.g. col. 7, line 61 - col. 8, line 26, 
"...any additional correlation data useful for later associating the event with other events to 
form transactions''); but does not specifically teach transmitting the correlated alarms to an 
enterprise management system to analyze across the network causes of the correlated alarms; 
the alarms and the correlated alarms are indicative of a degradation in service level or potential 
degradation in service level 

Roytman also teaches transmitting the alarms from the plurality of monitoring agents to an alarm 
correlation agent, which analyzes the alarms to produce correlated alarms, (e.g. col. 5, lines 13 - 
55); and 

transmitting the correlated alarms to an enterprise management system to analyze across the 
network causes of the correlated alarms, (e.g. col. 2, lines 34-51, "maps each managed-object- 
based alarm to a corresponding node... "). It would have been obvious to one of ordinary skill in 
the art at the time the invention was made to combine Roytman with Maccabee because utilizing 
a function that analyzes information across the network and the causes of the correlated alarms 
could isolate specific areas that are malfunctioning, (e.g., a down link), and have the network 
reroute information to other areas that are not affected so to lower latency in the system. 
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Medhat teaches the alarms and the correlated alarms are indicative of a degradation in service 
level or potential degradation in service level, (e.g., col. 8, line 54 - col. 9, line 15, "... react to 
any congestion that occurs, and to react when signs of impending congestion are found. "). It 
would have been obvious to one of ordinary skill in the art at the time the invention was made to 
combine Medhat with the combine systems of Maccabee and Roytman because notifying of 
congestion or imminent congestion conditions, could cause allocating resources more 
expeditiously, and forcing the bandwidth allocation system to re-arbitrate user parameters with 
the devices. 

As per claim 24, as closely interpreted by the Examiner, Maccabee teaches the step of 
determining a state of the business process from the value, (e.g. col. 3, lines 25 - 38). 

As per claim 26, as closely interpreted by the Examiner, Maccabee teaches the service level 
management domain comprises, an enterprise network, (e.g. col. 3, lines 25 - 38). 

As per claim 27, as closely interpreted by the Examiner, Maccabee teaches a method for 
providing an entity with service level management of a business process, the method comprising 
the steps of: 

monitoring a business process having at least one service associated with a service level 
management domain to provide service level management for an entity performing a business 
process, (e.g. col. 7, lines 37 - 60); 
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collecting data on one or more resources of a network associated with the service level 
management domain, the network being capable of performing one or more functions to provide 
the entity with a service to allow the entity to perform the business process, (e.g. col 7, lines 37 
-60); 

monitoring one or more parameters form the collected data the one or more parameter providing 
an indication of an operational characteristic of the service provided by the network, (e.g. col. 7, 
lines 37 - 60), but does not specifically teach the service having a predefined state expressed as a 
range of values; 

determining from the operational characteristic a value from the range of values, the value being 
a performance index of the service associated with the service level management domain 
indicating one of an acceptable state of the service, an unacceptable state of the service, or an 
imminent change from an acceptable state to an unacceptable state of the service; and 
taking an action to effect a change to the one or more parameters if the value indicates either the 
unacceptable state of the service or the imminent change in the state of the service. 
Roytman teaches the service having a predefined state expressed as a range of values, (e.g., col. 
7, lines 46 - 65); 

determining from the operational characteristic a value from the range of values, the value being 
a performance index of the service associated with the service level management domain 
indicating one of an acceptable state of the service, an unacceptable state of the service, or an 
imminent change from an acceptable state to an unacceptable state of the service, (e.g. col. 5, 
lines 13 - 55); and 
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Medhat teaches taking an action to effect a change to the one or more parameters if the value 
indicates either the unacceptable state of the service or the imminent change in the state of the 
service, (e.g., col. 8, line 54 - col. 9, line 15); It would have been obvious to one of ordinary skill 
in the art at the time the invention was made to combine Medhat and Roytman with Maccabee 
because of similar reasons stated above. 

Claim 23 is rejected for similar reasons as stated above. 

Claims 3-6 are rejected under 35 U.S.C. 103(a) as being unpatentable over Maccabee, 
Roytman and Medhat as applied to claim 1, and in further view of Koperda et al. (6230203) 
(hereinafter Koperda)* 

As per claim 3, as closely interpreted by the Examiner, Maccabee, Roytman and Medhat teach 
all that is described above that is similar in scope to claim 1, Roytman further teaches reporting, 
to a user, information regarding at least one of a group including availability, faults, 
configuration, integrity, security, reliability, performance and accounting of the measured level 
of service, (e.g. col. 2, line 18 - col. 3, line 44, "node status is propagated to application like the 
Solstice EM Viewer" & col 7, line 35 - col. 8, line 34, "window display 600"); and 
the component information representing operational data of one or more monitored components, 
(e.g. col. 2, line 18 - col. 3, line 44, "node status is propagated to application like the Solstice 
EM Viewer" & col. 7, line 35 - col. 8, line 34, "window display 600"), but does not specifically 
teach relating component information to a service upon which a business process depends, 
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determining a state of the business process based upon the component information, wherein the 
component information determines a measured level of service and wherein the level of service 
affects the operation of the business process. Koperda teaches relating component information to 
a service upon which a business process depends, (e.g. col. 1, line 65 - col. 2, line 41, "quality of 
play, parameters we considered include access time, delivery duration, bandwidth... " & col. 4, 
lines 2 - 64, "collects and reports statistics for level of service ")> 

determining a state of the business process based upon the component information, wherein the 
component information determines a measured level of service and wherein the level of service 
affects the operation of the business process, (e.g. col. 1, line 65 - col. 2, line 41, "quality of 
play, parameters we considered include access time, delivery duration, bandwidth... " & col. 4, 
lines 2 - 64, "collects and reports statistics for level of service "). It would have been obvious to 
one skilled in the art at the time the invention was made to combine Koperda with the combine 
system of Maccabee, Roytman and Medhat because utilizing a display to view the state of the 
business process could aid in a more efficient transmission system for when a transmission path 
is "jammed" and data needs to be redirected to a different path so the data can be delivered to its 
destination. 

As per claim 4, Maccabee, Roytman and Medhat do not specifically teach determining service 
parameters to measure the level of service. Koperda teaches determining service parameters to 
measure the level of service, (e.g. col. 1, line 65 - col. 2, line 41 & col. 4, lines 2 - 64, "collects 
and reports statistics for level of service "). It would have been obvious to one skilled in the art at 
the time the invention was made to combine Koperda with the combine system of Maccabee and 
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Roytman because of similar reasons as stated above. Furthermore, measuring the level of service 
aids in the determination of which alternate path data should use in the case of a congested 
network. 

As per claim 5, as closely interpreted by the Examiner, Maccabee, Roytman and Medhat teach 
all that is described above that is similar in scope to claim 1, Roytman further teaches 
representing the component information by one or more component parameters and wherein the 
component parameters are mapped into the service parameters, (e.g. col. 6, line 40 - col. 7, line 
35, "network alarms, alarm services module " & col. 7, lines 46-65, "critical, major, warning, 
minor... "). It would have been obvious to one skilled in the art at the time the invention was 
made to combine Roytman with Maccabee and because of similar reasons as stated above. 

As per claim 6, as closely interpreted by the Examiner, Maccabee, Roytman and Medhat teach 
all that is described above that is similar in scope to claim 1 , Roytman further teaches 
determining parameters with predetermined service levels, (e.g. col. 6, line 40 - col. 7, line 35, 
"network alarms, alarm services module " & col. 7, lines 46-65, "critical, major, warning, 
minor,.. "), but does not specifically teach whether service levels are satisfied by comparing 
service whether service levels are satisfied by comparing service. Koperda teaches whether 
service levels are satisfied by comparing service parameters, (e.g. col. 1, line 65 - col. 2, line 41 
& col. 4, lines 2 - 64, "collects and reports statistics for level of service "). It would have been 
obvious to one skilled in the art at the time the invention was made to combine Koperda with the 
combine system of Maccabee, Roytman and Medhat because of similar reasons stated above. 
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Claim 25 is rejected under 35 U.S.C. 103(a) as being unpatentable over M accabee and 
Roytman as applied to claim 23, and in further view of Bhoj et al. (6304892) (hereinafter 
Bhoj). 

As per claim 25, as closely interpreted by the Examiner, Maccabee, Roytman and Medhat teach 
all that is described above that is similar in scope to claim 23, Maccabee further teaches 
monitoring the service level of the service to monitor the business process, (e.g. col. 2, lines 21 - 
25 & col. 3, lines 25 - 38), but neither Maccabee, Roytman and Medhat specifically teach 
determining a service level of the service, the service level being defined by a service level 
agreement. Bhoj teaches determining a service level of the service, the service level being 
defined by a service level agreement, (e.g. col. 6, line 62 - col. 7, line 7); and 
monitoring the service level of the service to monitor the business process, (e.g. col. 6, line 62 - 
col. 7, line 7 & col. 7, lines 39 - 47). It would have been obvious to one of ordinary skill in the 
art at the time the invention was made to combine Bhoj with the combine system of Maccabee, 
Roytman and Medhat because when two system agree on a specific service level, the service 
provider could be guaranteeing 100% availability of the backbone of the service provider as well 
as the customer access circuit ordered by the service provider, making for a high level of service. 

Response to Arguments 

Applicant's arguments filed 03/07/2006 have been fully considered but they are not persuasive. 



Application/Control Number: 09/577,224 
Art Unit: 2143 



Page 1 1 



In the Remarks, Applicant argues in substance that Neither Maccabee or Roytman teaches or 
suggests subsequently analyzing the correlated alarms as set forth in the claims. At best, the 
references Maccabee and Roytman (upon with the Examiner appears to rely to teach these 
particular features of the claimed invention) individually appear to perform a single operation of 
analyzing alarms to produce correlated alarms. 

As to the first Remark, in response to applicant's argument that the references fail to show certain 
features of applicant's invention, it is noted that the features upon which applicant relies (i.e., 
subsequently analyzing the correlated alarms) are not recited in the rejected claim(s). Although 
the claims are interpreted in light of the specification, limitations from the specification are not 
read into the claims. See In re Van Geuns, 988 F.2d 1 181, 26 USPQ2d 1057 (Fed. Cir. 1993). 
Furthermore, Applicant admits that the prior art teaches the claim language as set forth above, 
(analyzing alarms to produce correlated alarms). Also, Maccabee teaches subsequent analyzing 
of alarms, (e.g., col. 8, lines 27 - 57, " ...correlation data subsequently used by the system to 
associate the event with other events into transactions "), and as also seen throughout the prior 
art. 

In the Remarks, Applicant argues in substance that the references relied upon by the Examiner 
do not pertain determining a performance index of the grade of service being provided in a 
particular service level management domains as disclosed in claim 23 and similarly in claim 27. 
For example, Roytman (upon which the Examiner relies to teach this particular aspect of the 
invention) apparently pertains to a severity level of an alarm, "such as, 'critical', 'major', 
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'warning', 'minor', 'normal', and 'indeterminate'." As would be appreciated by one of ordinary 
skill . in the art, these are relevant to a severity of a particularly alarm for particular network 
device and not applicable to a particular grade of service provided by a collection of network 
devices within the service level management domain. 

As to the second Remark, Applicant is asked to draw their attention to their claim language, in 
which it is noted that the performance index is not specifically defined in the claim nor the 
specification as to what the "index" could be. Furthermore, the "value" in a "range of values" is 
not specifically defined. Also, Applicant refers to "grade" as also being a "level". Roytman 
teaches such "level" which are utilized to the severity of the network or the quality. As seen in 
the prior art of Roytman, the severity level can be "normal" which is connected to a level or 
grade at which the network should be operating at or each separate node in the network, for 
example a server maybe working at a normal level given for their services. Also, the "range" of 
severity levels given by Roytman give the interpretation of how the network could be slowly 
degrading in service, i.e., "normal", "minor", "warning", "major" and "critical". Therefore, 
Roytman teaches the claims as broadly interpreted by the claim language. 

In the Remarks, Applicant argues in substance that the other claims that are dependant from the 
features of claim 23 and the prior art references utilized in the rejections under 103(a) fail to 
teach or suggest all the claimed features deficient from the references of Maccabee, Roytman 
and Medhat and therefore the rejections should be withdrawn therefrom. 
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As to the third Remark, Examiner would like to draw the Applicant's attention to the above 
responses to their remarks, for the prior art does teach the limitations of the claim language as 
stated by the Applicant. 

(10) Response to Argument 

In the Arguments, Appellant argues in substance that the invention, as recited in claim 
1, "mapping... events into alarms includes "detecting-events of a select type" and "mapping such 
events into alarms." Assuming arguendo that Maccabee teaches event "mapping," Maccabee 
teaches mapping events into transactions. As would be apparent to one of ordinary skill in the 
art, "transactions" and "alarms" represent different things. For instance, a "transaction" represents 
a series of processing stages associated with a task, request, application, etc., whereas an "alarm" 
is based on an operational characteristic of a network resource. 

In addition, the references relied upon, either alone or in combination, fail to teach or suggest at 
least the feature of "transmitting the alarms.., to an alarm correlation agent, which analyzes the 
alarms to produce correlated alarms," as recited in claim 1, for example. The Examiner alleges 
that Maccabee teaches this feature at col. 7, line 61 - col. 8, line 26. More particularly, the 
Examiner alleges by correlating events into transactions, Maccabee teaches "analyzing] the 
alarms to produce correlated alarms" because events sometimes include "additional correlation 
data useful for later associating the event with other events to form transactions." Final Action at 
3, paragraph 6. 

Following the Examiner's reasoning, which alleges that "transactions" are the same as "alarms," 
Maccabee would have to describe a system that analyzes the transactions to produce "correlated" 
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transactions. However, Maccabee fails to teach or suggest analyzing transactions or correlating 
transactions to produce correlated transactions. Rather, Maccabee only analyzes events to form 
transactions. 

As to the first argument, in which Appellant states that "an alarm is based on an operational 
characteristic of a network resource", is not exactly true, i.e., there are sections left out by the 
Appellant. The Appellants invention monitors operational characteristics and these 
characteristics that are detected are first "events" then mapped to "alarms". There is no teachings 
in the claims that would suggest that an alarm is anything else but a message as to what has 
happened in a network, either bad or good. As is stated in Maccabee, an event is a change in state 
of the system as an example stated in column 7, lines 38 et seq., 

"As depicted, sensors (200) interact with the software and hardware components through which 
the business transaction is processed, gleaning changes in state that result in the generation of 
events (205). Examples of sensors include software written to interact with software exits by 
registering for notification of select conditions (e.g., Lotus Notes Extension Manager); software 
and/or hardware written to intercept activities taken by the business transaction's software 
and/or hardware (e.g., interception DLL 's or shared libraries, or analysis of output logs or 
alert messages); or insertion of software and/or hardware probes within the business 
transaction f s software and/or hardware (e.g., ARM API calls within business transaction 
source code). If the change in state is such that an event can be generated, the Sensor further 
checks control rules (FIG. 2) e.g., filters to determine if it may generate the event. " 
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As can clearly seen the "operational characteristics" of a software and/or hardware is taken into 
account and an event is generated. Further into column 7 and into column 8 it is taught that the 
events that are generated are forwarded from a processor(s) to their agents, (e.g., col. 8, lines 25 
- 26, "Processors also forward the events they generate to their Agents (FIG. 2).")* Maccabee 
goes on further to discuss how events are correlated and collated with transactions based on logic 
contained within transaction generation rules. Furthermore, as stated in column 8, lines 33-40, 
"Correlation data can be any data deemed to be appropriate for later event correlation and 
collation within Transaction Records, and/or for report generation (e.g., to service selection 
requests for specific transaction records). Transactions are collections of related or linked 
events and/or other transactions . The event correlations (305) are based on common data 
attributes (correlation data) found within the events (205). " This would mean that one event 
could be correlated to a transaction and then linked to another transaction. Therefore, a type of 
analyzing of data would have to take place in order to "correlate" events to transaction and/or 
transactions to transactions, all of which are based on the change in state of a "network 
operational characteristics". Respectfully, Appellant is incorrect in assuming Maccabee does not 
teach or suggest analyzing transactions or correlating transactions to produce correlated 
transactions, as established above. Furthermore, when reviewing a reference the applicants 
should remember that not only the specific teachings of a reference but also reasonable 
inferences which the artisan would have logically drawn therefrom may be properly evaluated in 
formulating a rejection. In re Preda, 401 F. 2d 825, 159 USPQ 342 (CCPA 1968) and In re 
Shepard, 319 F. 2d 194, 138 USPQ 148 (CCPA 1963). Skill in the art is presumed. In re Sovish, 
769 F. 2d 738, 226 USPQ 771 (Fed. Cir. 1985). Furthermore, artisans must be presumed to 
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know something about the art apart from what the references disclose. In re Jacoby, 309 F. 2d 
513, 135 USPQ 317 (CCPA 1962). The conclusion of obviousness may be made from common 
knowledge and common sense of a person of ordinary skill in the art without any specific hint or 
suggestion in a particular reference. In re Bozek, 416 F.2d 1385, 163 USPQ 545 (CCPA 1969). 
Every reference relies to some extent on knowledge of persons skilled in the art to complement 
that which is disclosed therein. In re Bode, 550 F. 2d 656, 193 USPQ 12 (CCPA 1977). 

In the Arguments, Appellant argues in substance that Roytman teaches "transmitting 
the alarms ... to an alarm correlation agent, which analysis the alarms to produce correlated 
alarms" at col. 5, lines 23-55. However, the cited portions of Roytman merely relate to 
monitoring the state of various devices using an agent program (col. 2, lines 14-23). Even 
assuming arguendo that Roytman teaches generating alarms, Roytman nonetheless fails to teach 
or suggest an alarm Correlation agent, which analyzes the alarms to produce correlated alarms," 
as recited in claim 1 . Rather, Roytman logs alarms in a database and displays the alarms for an 
operator to view (col. 6, line 53 - col. 7, line 21). However, Roytman does not teach or suggest 
"transmitting the alarms... to an alarm correlation agent, which analyzes the alarms to produce 
correlated alarms,, as recited in claim 1. Medhat fails to cure these deficiencies of Maccabee and 
Roytman. For at least this reason, the rejection is improper. 

The references relied upon, either alone or in combination, also fail to teach or suggest at least 
the feature of "transmitting the correlated alarms to an enterprise management system to analyze, 
across a network, causes of the correlated alarms," as recited in claim 2, for example. The 
Examiner alleges that Roytman teaches this feature at col. 2, lines 34-51. However, the Cited 
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passage relates to a module that "maps each managed-object-based alarm to a corresponding 
node in a topology database." 

As to the second argument, Examiner would like to draw the Appellant's attention to the prior art 
of Roytman, specifically columns 5 - 7. It is stated in column 5, line 25 et seq. that a manager 
node may download the information that pertains to the alarms from the respective agents. This 
is also apparent in line 57 of column 5. Therefore, in the combination of Maccabee and 
Roytman, Maccabee 's correlation that happens at the agent is then transmitted to Roytman' s 
manager that would keep other records of alarms and/or events that happen in the network in 
their alarm log database 500. Although it appears that Roytman interchangeably uses events and 
alarms to mean the same thing, it is stated in column 6, line 55 that the agents generate events or 
traps, that could generally be referred to as alarms, from a response to conditions, which could be 
consider events that happen, which occur in the resources with which they are associated. As 
further noted above, it is Maccabee that teaches the correlated alarms and what might have 
caused the change in state as described in the cited areas above and herein. In Maccabee, column 
14, lines 30 et seq., it is stated that the links between the events and transactions take place and 
that the Tl, T2 and T3 are transactions or specific components that caused the event to happen as 
seen in T3, "ServerAccept" as once example. As can be seen in Figs. 11-14, with emphasis on 
figure 14, and the supporting text, Maccabee teaches the claimed language. Furthermore, 
Roytman also teaches what may have cause the alarm as stated in column 8, lines 22 et seq., 



Application/Control Number: 09/577,224 Page 18 

Art Unit: 2143 

"The alarms can also be filtered to select only those that match selected criteria. The criteria 
include managed object instance or the device triggering the alarm; managed object class or 
the type of device or resource generating alarms; alarm state or severity and event type, such as 
communications, Internet, etc. " 

Therefore, the combination of Maccabee's and Roytman's read on the Appellant's claim 
language. 

In the Arguments, Appellant argues in substance that the prior art of Roytman does not 
teach, "determining from the operational characteristics a value in the range of values, the value 
being a performance index of the grade of service associated with the service level management 
domain". 

As to the third argument, Examiner would like to draw the Appellant's attention to Figures 6 and 
7, where it is very clear that Roytman teaches a value in the range of values, i.e., critical, major, 
minor, etc, (e.g., col. 7, lines 54 et seq.). The Appellant appears to assume that the value has to 
be a numerical one. There is no such language in the claim and can therefore be interpreted in a 
broader sense. Furthermore, if their network is monitored under all the same rules for every 
device that would mean that their domain has a specific grade of service that is monitored by 
management and therefore it is understood that the network must operate under a specific level 
of service and if not an alarm is logged, as is taught by the prior art. 
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In the Arguments, Appellant argues in substance that there is no suggestion for 
combinding the references in the prior art and that the reasons for combining Roytman and 
Maccabee are improper. 

As to the last argument, it is clear that the teachings of Roytman would be obvious to combine 
with Maccabee, for one reason storing alarm information at a central location gives the 
management system the ability to view the different changes in the network, log then, and fix 
any problems that may occur in the network while keeping track of the status of network 
problems, (e.g., col. 7, lines 65 et seq.). Examiners motivation for combining is proper in view of 
the Supreme Court decision of KSR International Co. v. Teleflex Inc. et al. 
Therefore, the rejection still stands. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the Related 
Appeals and Interferences section of this examiner's answer. 

For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 
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